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Abstract 

An object-oriented basis for interdisciplinary compressor 
simulation can, in principle, overcome several barriers 
associated the traditional structured (procedural) devel- 
opment approach. This paper presents the results of a 
research effort with the objective to explore the reper- 
cussions on design, analysis, and implemention of a com- 
pressor model in an object-oriented (00) language, and 
to examine the ability of the 00 system design to accom- 
modate computational fluid dynamics (CFD) code for 
compressor performance prediction. Three fundamental 
results are that: 

1. The selection of the object-oriented language is not 
the central issue; enhanced (interdisciplinary) anal- 
ysis capability derives from a broader focus on 
object-oriented technology . 

2. Object-oriented designs will produce more effective 
and reusable computer programs when the tech- 
nolgy is applied to issues involving complex sys- 
tem inter-relationships (more so than when address- 
ing the complex physics of an isolated discipline). 

3. The concept of disposable prototypes is effective for 
exploratory research programs, but this requires or- 
ganizations to have a commensurate long-term per- 
spective. 

This work also suggests that interdisciplinary simula- 
tion can be effectively accomplished (over several lev- 
els of fidelity) with a mixed-language treatment (i.e., 
FORTRAN-C++), reinforcing the notion that 00 tech- 
nology implementation into simulations is a ’’journey” in 
which the syntax can - by design - continuously evolve. 

1 Aerospace Engineer, Senior Member AIAA 
2 Software Manager, Member AIAA 
3 Currently at Reese Air Force Base 


Introduction 

Gas turbine engine simulations of elementary form be- 
gan to appear about four decades ago, coinciding with 
the time two-spool engine technology was introduced. At 
that time, and with fuel-flow control problems as a back- 
drop, the increased engine technological complexity de- 
manded a more complete understanding of dynamic sys- 
tem behavior, and there was a need for analysis methods 
(mathematical models and their computer implementa- 
tion) leading to improved system control and perfor- 
mance (Fawke and Saravanamuttoo, 1971). Simulation 
contributions to the understanding of dynamic systems 
are as important today as they were in the 1950’s. For 
example, the recent work of Tryfonidis et.al.(1994) is an 
excellent example of the use of simulation in the interpre- 
tation of stall data, the development of signal processing 
techniques, and stall model development (the original 
goal of quantifying stall precursor data shed considerable 
light on the path-dependent behavior of the transition to 
surge). 

It is important to note that, historically, advances in 
simulation technology very closely follow refinements in 
dynamic system modeling, the evolution of computer 
languages, and improvements in computer hardware and 
operations. In the last two decades, major simulation 
software development paradigm shifts have been associ- 
ated with the migration from analog to hybrid comput- 
ers in the 1970’s, a shift to digital computing platforms 
in the 1980’s and subsequent advances in object-based 
compiler technology in the 1 990’s. 

To embark on the development of object-oriented sim- 
ulation is not a casual exercise since the resources re- 
quired to move in that direction can be significant. The 
attraction, however, is the promise of software reuseabil- 
ity that, if realized, can produce roughly a 20:1 return 
on the investment (see; for example, Nord\val!(1992)); 
the impetus for injecting object-oriented technology into 
simulation is a business decision, not a technical one. 
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Interdisciplinary Influence 

Most physical processes involve some coupling between 
scientific disciplines, and a key issue in simulation de- 
velopment strategy is the extent of the coupling, and 
to what degree the coupling influences or dominates dy- 
namic system behavior. 

Simulations are derived largely along discipline lines 
in which model development perspective often requires 
simplifying assumptions about discipline decoupling. Of 
concern is that, in the case of problems that are gen- 
uinely interdisciplinary, to what extent accuracy is jeop- 
ardized during the process of system decomposition, el- 
ement analysis, then system reconstitution (Denning, 
1990). In fact, decomposition strategy is even an issue 
on a single discipline level, particularly with highly cou- 
pled inlet-compressor problems (see the CFD discussion 
on page 4). 

More traditionally occuring in general simulation 
practice is an (interdisciplinary) blend of control sys- 
tem technology and aerothermodynamic cycle represen- 
tations, typically directed at, for instance, the develop- 
ment of integrated flight/propulsion control (IFPC) sys- 
tems (Shaw, 1988; Akhter, 1989). IFPC applications 
benefit from the ability to match time scales between 
the disciplines very closely. Advanced compressor perfor- 
mance requirements have brought to the forefront of in- 
terest active control problems once relegated to academic 
thought, but the challenge in matching the flow phy- 
ics and control system time scales is aggravated. When 
advanced control concepts are combined with stability 
assessment techniques and CFD for multistage compres- 
sor instability control, what was once a simple initial- 
value problem is also now a boundary- value problem; 
the length and time scale for the component-level model 
is at least an order of magnitude lower than the CFD 
calculation requirement (for stability). 

Another aspect of interdisciplinary coupling is aeroe- 
lasticity - aerodynamics coupled with structural dynam- 
ics. Consider an engine simulation intended to incor- 
porate compressor blade flutter. Figure 1, taken from 
Carta(1989) presents the interdisciplinary nature of the 
problem very clearly. As in the case for CFD, Aeroe- 
lasticity transforms what was once an initial- value prob- 
lem into what is now a combined initial-boundary-value 
problem. Thus, in the interdisciplinary area, some fun- 
damental implementation issues are: 

1. The W raw” number crunching capability required to 
solve unsteady aerodynamics and structures prob- 
lems simultaneously, 

2. Mismatched fidelity of the simulation modules 

3. Developing effective (or standard) means to intro- 
duce geometric data into the simulation, and 

4. Software manageability. 


Scope of Work 

Object-oriented (00) technology has the appealing po- 
tential to bridge advanced computer technology and 
high-fidelity mathematical problem formulations to ben- 
efit interdisciplinary simulation and analysis of gas tur- 
bine compressors. Although the 00 approach sounds 
good in principle , what can we expect in practice? An 
implementation exercise is an effective way to answer 
this question. In the present work, exercises involving 
the development of a prototype 00 simulation (frame- 
work) are discussed; this project was motivated by the 
conspicuous absence of direct experience in assessing the 
benefits of 00 environment for gas turbine applications. 
Activities to date include exercises in 00 code develop- 
ment, external (someone other than the code author) re- 
view of subsequent software modules, post-development 
code modification experience, and the exercise of devel- 
oping a simple interface between a map-based compo- 
nent level model (CLM) and a computational fluid dy- 
namics (CFD) code. 

Experiences with the prototype codes were intended 
to focus primarily on the compressor portion of the tur- 
bine engine, though at the outset the complete engine 
had to be considered in the analysis and design process. 
NASA Lewis Research on gas turbine 00 programming 
has been underway for approximately four years, from 
which two prototype programs have been developed: 

1. A prototype LISP 00 code, developed for the com- 
plete engine system, and, 

2. A C++ code, developed to explore compression sys- 
tem simulation issues. 

Specific concepts of interest in code development in- 
clude: creation of a traditional map-based compres- 
sor model, development of a computational fluid dy- 
namics interface model, and use of the 00 inheritance 
concept to create perturbations of these models. Ex- 
ercises undertaken represent very specific attempts to 
quantify the benefit of the object-oriented programming 
approach (though largely from an aerothermodynamic 
standpoint). 

Of particular interest is the LISP exercise, in which 
the prototype was instrumental in setting the stage for 
subsequent object-based research activities; the disposi- 
ble prototype mentality liberated individuals to pick and 
choose modules from the LISP carcass. 

In the discussion to follow, we first highlight some of 
the recurring simulation issues that were the catalyst 
for a look at the 00 approach, and then consider is- 
sues associated with typical compressor representations 
(again, from a simulation point of view). After a brief 
introduction to key object-oriented concepts, the analy- 
sis and design of the prototype codes are presented and 
discussed. 
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Simulation Issues 


Traditional Simulation Process 

Gas turbine engine simulations are normally intended to 
mimic dynamic or steady-state engine behavior through 
a computer solution to a mathematical representation of 
the engine cycle. Figure 2, based on the work of Szuch 
et. al.(1982), illustrates seven key steps in the simula- 
tion development process. First, the formulation of the 
mathematical model involves the appropriate applica- 
tion and tailoring of conservation laws (discipline spe- 
cific) to the perceived system attributes (physics); the 
complete mathematical method development includes 
equation solver strategies. After mathematical methods 
are established, it is then necessary to prepare data re- 
flecting specific engine design detail and operating en- 
vironment characteristics. The next step, implemen- 
tation, links the methods and data through the cre- 
ation of a computer code based on a computer language 
(syntax). Traditionally, implementation expectations are 
highly coupled to formulation strategy . 

The fourth step in the process, simulation evaluation 
and validation, is where computed results are compared 
with design/performance data. Inevitably, a discrepency 
between calculated response and data occurs; this is usu- 
ally attributable to either an error in the mathematical 
method or in the formula translation. Again, with Figure 
2 in mind, a modification is usually necessary (to resolve 
the error) and the assessment of what is required may 
take the analyst back to either the formulation or imple- 
mentation stage. Once the simulation results have been 
validated, documentation of the simulation design (and 
related methods) then (hopefully) takes place. Finally, 
if, for instance, the effect of design changes are of inter- 
est, the simulation development process just completed 
is repeated; it is often the intention for the simulation 
framework to be robust and applicable to a new systems 
with minimal effort. 

Gas turbine simulation design usually evolves from 
a convenient and natural decomposition of the en- 
gine according to component functions (component level 
model), e.g., an engine is represented as the assembly of a 
compressor, burner, turbine, and interconnecting ducts. 
As an example, the turbofan engine schematic shown in 
Figure 3 has the component level model (CLM) repre- 
sentation shown in Figure 4. 

Mathematically, the objective of modeling is to re- 
duce the system to a set of ordinary or partial differ- 
ential equations that represent the dominant physics of 
the system. For a typical real-time simulation, a vector 
of state variables (spool speed, pressure, temperature) 
is identified where generally the number of parameters 
in the state vector is a function of the engine fidelity 
(complexity) desired. 


Four Key Issues 

Numerous obstacles and limitations to existing sim- 
ulation are described in the work of Drummond et. 
al.(1992), but only the following summary is essential 
to repeat here: 

1. Procedural code strictures predominate existing 
(large-scale) simulation codes and the ensuing ap- 
proaches are constrained to be either general, sim- 
ple, or accurate, but a simulation that is any com- 
bination of these is not currently available (in the 
public domain). Work-arounds to simulation con- 
straints usually involve some compromise whereby, 
for instance, diminished model fidelity is exchanged 
for increased simulation execution speed, or where 
simulation generality (flexibility) results in alack of 
program simplicity. 

2. Discipline isolation is relatively predominant for 
the’usual’ simulation. Interactions between, for in- 
stance, aerodynamics, structures and controls is ac- 
tually fairly limited during mathematical modeling 
of component characteristics. A requirement also 
exists for the simulation to deal with a continuum of 
time and length scales, and for component geomet- 
ric characteristics to be introduced in a manageable 
fashion. 

3. Simulation languages and architectures tend to 
assume a single-processor hardware environment 
which impedes software portability to modern par- 
allel and distributed computing environments; this 
leads to a "strategic fit" philosophy in which simu- 
lation methods are not designed to exceed perceived 
implementation limitations. 

4. Simulation initialization and balancing is non- 
trivial for arbitrary engine configurations, especially 
for highly non-linear systems where a high fidelity 
simulation is required. Tools for initialization and 
balancing are never noticed (by the user) when the 
simulation runs without error. The "inexact sci- 
ence” needed to diagnose problems and take correc- 
tive action is frequently an understated aspect of 
system simulation. 

Object-oriented technology can help alleviate the first 
three of these simulation issues; initialization and bal- 
ancing problems don’t go away - they just have a new 
look. 

In the next section several issues specific to compresor 
simulation are discussed. 
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Compressor Simulation Issues 

Compressor simulation is always accompanied by em- 
piricizm (for unresolved scales) due to the diverse range 
of length and time scales associated with the governing 
physics. At one extreme, the simulation engineer may 
be interested in post-stall system behavior, for which 
the fidelity offered by a compressor ’map’ representation 
will suffice. On the other hand, compressor performance 
predictions reflecting the influence of detailed flow struc- 
ture require 3-D CFD analyses and sophisticated flow 
modelling. Traditional treatment has dealt with these 
extreme situations separately, requiring different hard- 
ware platforms and solution strategies for the effective 
use of computational resources. It has been suggested 
that advanced simulations should and can be structured 
to accommodate both in a seamless fashion. 

The essence of the present work is to explore meth- 
ods which integrate what heretofore have been isolated 
problem analysis techniques. More specifically, the con- 
cept of zooming is proposed as a tool for spanning a 
larger range of length and time scales in a problem than 
previously achievable; zooming is a temporary excur- 
sion to accomodate higer fidelity methods. The door to 
managing the implementation of the zooming concept 
opened when object-connector technology crossed paths 
with distributed processing. 

To accomplish the goal of prediction or advanced sim- 
ulation of compressor operating characteristics requires 
existing simulations entertain demanding new levels of 
fidelity and interdisciplinary coupling. 

Non-Dimensional Maps 

A major task in turbofan engine modeling is predicting 
the aerothermal performance of the major components 
of the engine. An acceptable compromise to the descrip- 
tion of turbofan component performance is a representa- 
tion based on non-dimensional analysis. This approach 
yields multivariate component ’’maps” which detail base 
component performance over a wide range of operating 
conditions. 

To get an idea of component map implementation 
logic, a sample fan logic diagram from an F100 simula- 
tion is presented in Figure 5. Note the procedural nature 
of information flow; the complete simulation logic dia- 
gram represents a well-orchestrated (by the programmer, 
not the compiler) integration of controls and aerother- 
modynamic representations ... representations not easily 
modified! 

The non-dimensional performance map is a relatively 
straight forward and an intuitively pleasing approach to 
compressor performance modeling. However, as a prac- 
tical modeling technique, the approach has some signif- 
icant drawbacks. Traditional performance maps are not 
easily scaled; therefore the maps are limited in their use 
for modification of component performance to account 
for new data and/or component sizing studies. Further- 


more, modeling of component off-design performance 
can require additional maps consuming large amounts of 
computer memory. A key feature of hybrid simulation 
was the storage of component maps on the digital com- 
puter and the communication with and solution of the 
differential equations on the hybrid computer (in addi- 
tion, of course, to the real-time capabilities of the hybrid 
computer). 

The drawbacks in the traditional turbofan component 
performance maps led to the development of alternative 
methods of modeling component performance. Converse 
and Griffin (1984) developed a ’’backbone” performance 
fitting technique based on the physics of the component 
rather than curvefits of nondimensional parameters. The 
beauty of the approach is compromised by its complexity 
(of course, this diminishes considerably through concept 
familiarization). A very basic block diagram to describe 
the backbone approach, Figure 6, belies the significant 
additional procedural logic required for the backbone im- 
plementation. 

Performance maps and backbone representations are 
appropriate techniques for the scope of many current 
and future simulation efforts. However, they represent 
static descriptions of component performance and cre- 
ate difficulties in developing, for instance, a high-fidelity 
dynamic system simulation study of rotating stall. Be- 
cause this specific example is an active area of research, 
work-arounds (in the form of modeling) are beginning to 
emerge. Nevertheless, the traditional focus on aerother- 
modynamic (or any isolated discipline) performance pre- 
cludes interdiscipinary system simulation. The role of 
component representations of a more fundamental na- 
ture (based on theories of fluid mechanics or elasticity) 
is becoming apparent. 

CFD Predictions 

An approach to component representation based on first 
principles is desireable, but as a practical matter is dif- 
ficult to accomplish on a typical (single processor) sim- 
ulation computing environment. Another issue is that 
several fundamentally different CFD approaches can be 
entertained, so there is extensive 00 analysis and design 
work required before a transparent CLM-CFD handoff 
process can be accomplished. Central to this is the defi- 
nition of compressor geometry, and the implementation 
of standards for blading. Modiano et. al.(1994) have re- 
cently explored object-oriented grid blocking techniques. 

An innovative technique for effective CFD perfor- 
mance predictions is given by recent research by 
Tan(1994), in which methods are presented for assess- 
ment of compressor performance degradation due to in- 
let distortion. In that effort, an Euler solver is coupled 
with a model for body force terms; this provides a fairly 
computationally effective scheme that is currently being 
examined for possible porting to an object-based con- 
struct. 
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In exchange for the simplicity of the scheme, there 
arises the need to match (numerically) the upstream 
influence the compressor has on the 3-D inflow when 
the compresor is assumed axisymmetric. Further, when 
matching the distributed field solution with the lumped- 
parameter CLM model, the exact field integration tech- 
nique is not always evident (see, Wyss et. al. 1993). 

The Object-Oriented Perspective 

A fundamental question to ask is: What needs to be 

changed in current simulation practice? 

From a programming perspective the view of Schoef- 
fler(1992) provides a good response: 

1. Structure, structure, and more structure. 

2. Modules that can be used like building blocks. 

3. Modules which are application oriented. 

4. Modules which can be reused. 

5. Modules whose source code need not be changed to 
reuse them. 

Reusability is a central issue (Meyer, 1987). One can 
begin to see that many of the conveniences associated 
with the ’usability’ of FORTRAN hinder, in the context 
above, its ’reusability’. Furthermore, it starts to become 
clear that a computer language that has the attributes 
stated above would be the desired language for simu- 
lation - object-oriented languages appear to fit the re- 
quirements; specific features supporting this follow later. 

In conjunction with the above, traditional (digital) 
simulation developers find it impossible to resist cus- 
tomizing code and tailoring solution techniques to the 
specific problem and performance window at hand (the 
’’need for speed”); this has far-reaching manageabil- 
ity effects that include documentation, reliability, main- 
tainability, and re-useability of the subsequent code. 
Application-driven efforts require flexibility in the multi- 
fidelity simulation. 

In this section, we try to answer three frequently asked 
questions: 

What is object-oriented programming? 

How is the object-based approach different from a 
subroutine-based FORTRAN program 

Why do we need another programming language? 

It is proposed that an object-oriented (00) design 
approach to gas-turbine simulation has the potential 
to overcome many of the simulation obstacles outlined 
above. In the 00 approach, emphasis on modeling 
objects (instead of proceses) and the relationships be- 
tween objects , holds the key to developing and manag- 
ing simulations for complex gas-turbine systems. Robust 
strategies for implementing an 00 perspective have been 


made possible by the recent accessability of object-based 
languages 2 and widespread availability of powerful com- 
puting platforms 3 : the enabling technology is ready and 
waiting. 

The Terminology 

New terminology is usually introduced with any new 
technology. Below are given our interpretation of the 
key terms used in the analysis and design process. 

Classes 

When looking at the actual code for an object-oriented 
program, nowhere will one find mention of objects. Ob- 
jects are merely instances of the more general concept of 
a class. A class is usually described as a group of like 
objects (classes may also be thought of as templates for 
objects). A distinct object is created when a specific set 
of ’’values” is assigned to the attributes, that is, when 
an instance of an object is created (instantiated). 

Objects 

What is an object? Objects are defined in terms of 
classes. A class is a group of objects that have the 
same attributes (length, area, inlet pressure) and meth- 
ods (equations for state variable time derivatives). The 
individual values of the attributes of a particular class 
are set by creating an instance of the class. For example, 
Figure 4 illustrates that there are several intercomponent 
ducts in the engine. The unique values of the duct’s at- 
tributes are what distinguishes one duct from another. 
They are all members of the class of ducts and thus share 
the same analytic model. 

Objects are the building blocks of an object oriented 
program. An object is a package containing a set of 
variables, called attributes, and a set of functions, called 
methods, that operate on the attributes. In an object- 
oriented program, the code is organized around the data. 
That is, data and functions to manipulate the data form 
a complete unit to model real world objects. In contrast, 
procedural codes are organized around the equations or 
functions, with the data being passed to the function 
when needed, or automatically via common blocks. 

Attributes and Methods 

Attributes and methods give the object its appearance 
and behavior. An attribute is basically a variable. It 
may be more appropriate to think of an attribute as a 
piece of data that helps define the state of an object. 
Methods are simply functions. However, they are very 
tightly coupled to the attributes of the object in which 

2 Which has been directly influenced by advances in compiler 
technology 

3 Fueled by the proliferation of inexpensive ’486 computers and 
the availability of inexpensive C++ software. 
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they reside. That is, methods exist to perform opera- 
tions on the the attributes. 

Messages and Associations 

Objects communicate by sending messages through con- 
nections called associations. A message is simply a call 
to one of an object’s methods. Associations are the 
interactions between objects. The association defines 
such things a s how messages are passed between objects, 
what knowledge an object has of other objects, and what 
methods are accessible to other objects. Messaging is a 
way of enforcing clarity in the realtionships between ob- 
jects - ”ask, don’t touch” (Winblad et.al., 1990). 

With the recent work of Schoeffier(1994) in mind, the 
philosophy of messaging is an enabling mechanism for 
distributed processing and the concept of ’’zooming.” 
Zooming is a process in which adjacent components can 
communicate even when component fidelity levels are 
different (pressure and temperature grid resolution dif- 
ferences). Central to effective messaging in the present 
work are the use of connectors for scale integration (dis- 
cussed in more detail later). 

Inheritance 

Inheritance is the sharing of methods and attributes by 
similar classes. When a class is drived from another, it 
inherits the essence of the base (parent) class. 

An emphasis in our previous discussion has been to 
pose simulation obstacles in the context of a traditional 
simulation development approach. Here, we provide our 
perception of what constitutes an object-oriented (00) 
approach, and remark on some differences between 00 
and traditional procedural code features. Then, some 
fundamental object representations are presented. Fi- 
nally, the sections which follow provide the results of ex- 
periences with the LISP and C++ project explorations. 

A Remark on the References 

Literature on object-oriented analysis, design, and lan- 
guages is abundant 4 and continues to grow. The work 
of, for example 5 , Shaw (1992), Smith (1991), Steele 
(1984), Booch (1986), and Flaming (1991), provide a 
window to the world of 00 technology. Of the numer- 
ous references consulted during the course of this re- 
search project, especially noteworthy introductory dis- 
cussions are given in the work of Ince (1988) as a per- 
ceptive commentary on the ’software baroque’, and by 
the work of Taylor(1991) on the motivation and ratio- 
nale behind the object-oriented philosophy. Germaine 
to the present focus, however, are two reports. The first 
is the report of Holt and Phillips (1991), which deals ex- 
plicitly with a Lisp object-based implementation of the 

4 A trip to any major University bookstore is a stunning example 
of just the textbooks that are available. 

5 To be sure, there are numerous other papers and books. 


DIGTEM(Daniele et. al., 1983) gas turbine engine code. 
The second is the work of Cannon(1993) dealing explic- 
itly with the construction of C++ compressor objects. 

Designs Oriented to System Objects 

The system and compressor codes each began with an 
analysis of the system to be modelled and a design of 
the model to represent the system. 

Designs based on object-oriented principles differ from 
traditional designs in the way the (perceived) system is 
decomposed. A traditional approach identifies the ma- 
jor steps in the overall process - a so-called functional 
decomposition - while 00 approaches involve a system 
decomposition into physical entities, or objects 6 . Such a 
view of the system has lead to the notion of 00 design 
and analysis as a way of ’modeling reality’; a more pre- 
cise definition is evasive because the 00 approach can be 
characterized as a collection of concepts which together 
describe a paradigm shift in software development (Tay- 
lor, 1991; Winblad et. al., 1990). 

Certainly, the object-oriented paradigm invloves con- 
cepts which are not difficult to understand in themselves, 
but they collectively do imply (require) a new way of 
looking at and analyzing complex systems. Booch(1986) 
provides a useful outlook: 

’’Read the specification of the software you 
want to build. Underline the verbs if you are 
after procedural code, the nouns if you aim for 
an object-oriented program.” 

Again, the intent in departing from traditional methods 
goes beyond the task of producing a working simulation 
for a specific component - it is moreso an ongoing ef- 
fort to provide an infrastructure which inherently has 
the capability to rapidly produce a wide range of (new 
and existing) system configurations involving multiple 
disciplines and varying degrees of fidelity. The ’’correct” 
design will not change the outcome, just the journey. 

The Initial Prototype 

The first attempt at an object-based view of a gas tur- 
bine system was forged through a joint effort between GE 
(Lynn, MA) and the NASA Lewis Research Center. This 
effort was started in 1989 and contined for approximately 
3 years. Although an operational code was developed, 
the more lasting impact of the work was the following: 

1. The proof-of-concept for an object-oriented pro- 
gramming approach in gas turbine simulation. 

2. A demonstration of the effectiveness of ’’shrink- 
wrapping” FORTRAN code with an object-oriented 
language. 

6 Generally speaking, object definitions are not restricited ex- 
clusively to physical entities; objects can also be, for example ab- 
stractions of events. 
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3. The identification and initial development of 
connector-object technology. 

Prior to this exercise, there were no known object- 
based simulations (in the public domain) and the notion 
that an object-based simulation methodology would be 
successful was based simply on conjecture. To keep our 
results in the public domain as much as possible, a non- 
proprietary component level model (CLM) code was se- 
lected as the baseline simulation. It is fairly straightfor- 
ward in the CLM structure (recall Figure 2) that each 
component of the system (i.e. fan, compressor, combus- 
tor, etc), as well as the generic mixing volumes, can be 
represented a s an object. Each object has characteristics 
(like state variables) and functions (equations for state 
variable time derivatives) which are combined together 
to create a complete definition of the object. In general, 
when surveying a gas turbine, anything that is worth 
talking about is probably an object. 

Analysis and Design Effort 

The result of connecting the components and mixing vol- 
umes together with connector groups is a system. How- 
ever, it is necessary to bring these objects together un- 
der an umbrella system object. The system defined by 
connecting components and mixing volumes together is 
strictly a static description of the system. It is necessary 
to define the system object (which contains the compo- 
nents, mixing volumes, and connector-groups) in order 
to provide the actual simulation methods (steady-state 
or transient). 

A non-proprietary engine model, DIGTEM (Daniele 
et. al., 1983), was selected for decomposition and im- 
plementation in the Common Lisp Object System. 7 A 
graphical user interface was developed to simplify the 
creation and execution of the system. 

A class hierarchy, shown in Figure 7, was created to 
provide a general framework for simulation model devel- 
opment. In principle, the framework allows simulation 
models across varying levels of fidelity and disciplines, 
and a structures code was identified to be married with 
the aerothermo cycle code (structural object definition 
was not completed). 

Code Structure 

The process of transforming the original DIGTEM code 
was a gradual efTort. This suggests (correctly) one ap- 
proach to object-oriented programming is that in which 
the code is not written entirely in, for instance, Lisp or 
C++. As mentioned earlier, the idea is not to assume 
that an object-oriented language is synonymous with the 
idea of object-oriented technology ; although potentially 
clumsy, many different languages can be used to imple- 
ment an object-based design. 

7 This novel use of Lisp resulted in this research sometimes being 
referred to as the ”Lisp Project” 


To reduce development cost of the prototype develop- 
ment, it was appropriate to reuse existing FORTRAN 
code wherever possible. 8 Such an approach does require 
some rehabilitation of the FORTRAN subroutines. For 
instance, all COMMON, DATA, and EQUIVALENCE 
statements must be removed if, within a given subrou- 
tine, the data could otherwise be passed through the sub- 
routine argument list. In the DIGTEM case the "general 
cleanup” of the FORTRAN required: 

1. A cataloging of all variables in the code to identify 
unnecessary variables, dummy variables repeatedly 
reused for different purposes (at different points in 
the procedural calculation sequence), 

2. The eradication of all COMMON blocks, and mi- 
gration of the effected variables to the subroutine 
calling argument list, and 

3. Identification of modules fundamentally redundant. 
The effect of this action was threefold: 

1. There was a large increase in the argument lists for 
eash subroutine 

2. The DIGTEM subroutines are now highly cohesive 
and loosely coupled to one another. 

3. The communication between the subroutines is min- 
imized, only the appropriate arguments are passed. 

Also, subroutine names were changed to represent the 
actual components of the engine; this reflects a migration 
of the code to an object-based system. It is revealing to 
provide samples of actual code to reinforce these points. 
Sample class definitions are given in Figures 8; the in- 
stantiation and coupling of objects is shown in Figure 9. 
The FORTRAN-Lisp mixed language approach to the 
prototype is manifest in "foreign” object calls, as shown 
in Figure 10. Rehabilitation of FORTRAN compressor 
argument list - to eliminate COMMON and EQUIV- 
ALENCE statements - produces a generic compressor 
code, as illustrated in Figure 11. 

An interesting feature of the prototype development 
is that the conversion was evolutionary. The basic LISP 
shell was operational, but a great deal more could be 
done to adhere to the religion of object-oriented design. 
Although inheritance and reuseability features were por- 
trayed in the prototype to a limited extent, nonetheless, 
reusability was, in fact, demonstrated. An important 
message is that during the implementation of object- 
oriented technology for simulation, a paradigm shift does 
not mandate a software programming revolution (as long 
as the appropriate heirarchy and object-definition road- 
map are in place). A derivative of the original graphic 
user interface, Figure 12, was, at the time, an impressive 

®Again, the idea was to shrink-wrap FORTRAN routines with 
LISP 
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interface for the code operation, and the draging of icons 
across the screen was an enjoyable alternative to the tra- 
ditional procedure involving a manual input deck build. 
This automation of relationship definition did, however, 
require a significant effort in the prototype effort. For 
complex system simulations, GUI development is abso- 
lutely essential, not just a ”fun and interesting” thing to 
do. 9 

Connector Groups 

Although the components and mixing volumes are the 
fundamental building blocks of the LISP simulation sys- 
tem, connector groups are the means by which compo- 
nents and mixing volumes communicate with one an- 
other. Connectors are represented as objects in the sys- 
tem; in the prototype simulation, key connector groups 
defined are parameter groups, zoom processors, and feed- 
back connectors. Parameter connectors are a means 
to communicate individual parameters of a particular 
discipline between components and mixing volumes. A 
zoom processor connects component models of differing 
fidelity. Feedback connector groups permit the creation 
of closed-loop systems. 

Parameter connectors allow for convenient interdisci- 
plinary system definitions. Zoom processors assist in 
creating system simulations accommodating a variety of 
length and time scales (recall the mismatched fidelity is- 
sue discussed earlier). Schoeffler(1994) has extensively 
explored the connector concept, and his research de- 
scribes the value of connectors as agents of message pass- 
ing and scale integration - these concepts are relevant to 
the development of zooming and distributed processing 
capabilities. 

Discussion 

Different classes of objects in the LISP code share com- 
mon methods and attributes through a mechanism called 
inheritance. For example, a variable compressor inherits 
most of its definition from the class of compressors. In 
turn, compressors are a kind of rotating part and thus 
inherit behavior from the class of rotating components. 
The goal of this approach is to eliminate redundant code 
development and maximize the generality of the model. 
With this general approach in mind, it is necessary to 
look for a generic starting point to define the system. In 
the prototype engine cycle the most general object is a 
fixed control volume. From this, components and mix- 
ing volumes are established. Components are associated 
with real physical entities (compressor, turbine) which 
transform energy from one form to another. Unlike mix- 
ing volumes, no energy can accumulate within the con- 
trol volume. A more detailed description of the generic 
mixing volume concept is given in Holt and Phillips 
(1991). 

9 Again, see Windblad(1990) for further discussion 


An extensive validation effort went into the original 
DIGTEM model, so the relative success of the object- 
based implemetation is manifest in the lack of differ- 
ence between the original (FORTRAN) and Lisp state- 
variable profile predictions. The icon-based graphic 
user-interface simplifies system model development; it 
is not required of the user to modify any source code 
to create simulations of new configurations (really). 
An interesting byproduct of this effort was the defi- 
nition of a very robust set of subroutines for the de- 
scription of the physics (any reminants of the ” solver” 
were removed from the subroutines). Subsequently, a 
DIGTEM-ADPAC zooming exercise (Reed and Afjeh, 
1993) was made possible by the LISP effort for subrou- 
tine redefinition. An issue in that particular zooming 
exercise was the manner in which the CFD result is most 
appropriately integrated to match the CLM lumped- 
parameter specification (again, the subtle integration 
dilemmas presented by Wyss(1993) take on a new im- 
portance!). 

Figure 13 is a comparison of the baseline FORTRAN 
and LISP code results for thrust, HP spool speed, and 
LP spool speed variations, driven by scheduled ramp 
changes in fuel flow and nozzle area. There is an offset 
in the curves associated with the definition of the com- 
pressor map data for the original FORTAN code that did 
not have an exact translation in the object-based envi- 
ronment. The map splits represented a mathematical 
convenience for which the FORTRAN code procedures 
were designed to accommodate. Object-oriented tech- 
nology was pushing the fan to be treated - appropriately 
so - as a single component. 

The Compressor Object 
Demonstration Exercise (CODE) 

Two basic observations were the motivation for the 
C++ project. First, the zooming concept could not be 
tested within the framework of the LISP project, so an 
alternate simulation path needed to be in place. Sec- 
ond, in comparison to the widespread growth of C++ 
an object-oriented language, LISP programming was 
viewed more of as an AI language which exhibited a 
number of object-based characteristics. 

Time did not permit a complete exercise in which com- 
pressor performance predictions went from Map objects 
to CFD, then back to the Map object, but a number 
of essential object-based features were established. Re- 
call that the zooming concept involved the transparent 
replacement of the map-based compressor representa- 
tion with a higher fidelity computational fluid dynamics 
(CFD) numerical model. 

Analysis 

Analysis of the problem first determined the expected 
function of the program: CODE would serve as a pro- 
totype compressor simulation that would demonstrate 
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the ability to be easily modified, and therefore be posi- 
tioned to address new simulation issues. For simplicity, 
the code would be based on the data and maps of the 
validated DIGTEM steady-state compressor model. 

Many techniques exist for system analysis; one alluded 
to earlier was to write down a statement of the problem 
and picking out the nouns to represent objects and the 
verbs to represent associations. Objects and associations 
for the compressor are shown in Figure 14; again, these 
were based on the DIGTEM component level model phi- 
losophy. 

Two basic kinds of associations were used in CODE. 
The 1:1 and 0:M symbols refer to the minimum and max- 
imum number of objects that can exist at the other end 
of the association. The 1:1 association means that the 
compressor must be associated with one and only one up- 
stream object (i.e. the fan). The 0:M association means 
that the compressor can have many bleeds or not at all. 

Design 

Whereas the analysis phase of the project determined 
what was to be simulated, the design phase determined 
how was to be done. During the design phase, the fun- 
damental representations and appearance of the compo- 
nent objects and the structure of the associations were 
determined. In essence, a ’’blueprint” for the system was 
created. 

The fundamental representation of a component ob- 
ject refers to the way in which the mathematics are de- 
scritized (organized) to represent the ”real world”. Ex- 
tensive thought and discussion went into deciding on this 
representation. The pitfall in adhering to the CLM for- 
mat is, for instance, in the representation of the control 
volumes. In the Lisp project, control volumes were re- 
quired inbetween all (other) objects. Recalling that fun- 
damental tenant of the object-oriented design philosophy 
is to model the real world, it became clear this situation 
was not satisfactory. The trap was a formulation based 
on the procedural mindset. Thus, the object-based con- 
trol volume representation shown in Figure 15 illustrates 
the decision to eliminate a separate volume (in compar- 
ison with Figure 12, for instance). 

It is worth remembering that, traditionally , volume 
dynamics were moreoften included in simulations in or- 
der to assist in the numerics of the problem, not for 
resolution of the gasdynamics. This facet of simulation 
went unchecked in the initial Lisp prototype develop- 
ment, and thus volume elements had a prominent role 
in the system description. Frequently, the volumes used 
in the simulation had very little relation to the physical 
size of the component, and numerical values for volumes 
were often adjusted to ease numerical balancing or allow 
an increase in characteristic time. 

Treatment of the performance maps also brought into 
question the basic architecture of the Lisp experiment. 
At first it seemed natural to make the maps as objects 


since there were both data and methods to operate on 
that data. In fact, an early version of the program 
employed map objects, but since the calculated perfor- 
mance of the compressor (a map-based one) depends on 
the map data, it appeared equally plausible that the data 
should be a part of the compressor object, and the meth- 
ods to manipulate the data should exist alongside those 
for calculating such things as pressure. The latter repre- 
sentation was ultimately used. Another approach would 
be to make the maps objects, but to encapsulate them 
within the compressor object - that is, instantiate them 
within the compressor data. The essence of the system 
design is contained in the Instance Diagram shown in 
Figure 16. For brevity the attributes and methods are 
not shown, though the associations that were used are 
noted. A simple pointer was used to construct a 1:1 asso- 
ciation. An unordered set object containing pointers to 
component objects was selected for the 0:M associations. 

Simulation Framework 

A simulation framework - a hierarchy of classes as shown 
in Figure 17 - was used to provide the necessary flexi- 
bility and reusability to allow the design to deal with 
advanced simulation issues. 

The framework was structured such that class gener- 
ality was commensurate with heirarchical position. For 
instance, the EngineElement class was the most general 
and contained all the characterisitcs common to all el- 
ements of the engine. One level down, the engine el- 
ements were divided into more specific classes of ob- 
jects: those that rotate, those that resemble a control 
volume, those that have variable geometry, and those 
that have a performance map. Adding specificity to the 
lower classes in the heirarchy amounted to adding new 
methods and attributes to the basic features inherited 
from the based class (parent class) to distinguish them 
from other classes. For example, the MappedElement 
class took the fundamental functionality defined in the 
EngineElement class and added to it the ability to load, 
print, and interpolate DIGTEM’s performance maps. 
Note that some methods were superseded (or overrid- 
den) by methods in the derived class. 

The basic principle behind the Simulation Framework 
- a set of classes which define the appearance of ob- 
jects but not their behavior - was derived from the 
Object Windows Library marketed by Borland Interna- 
tional. The Object Windows application framework was 
designed to save developers of Microsoft Windows appli- 
cations from having to define new methods to handle ba- 
sic Windows tasks (like drawing windows on the screen) 
each time a new application is developed. Classes in the 
framework have the basic functionality needed to build 
objects that will run under windows, but they do not 
define specific behavior. The developer can derive a new 
class from the framework and inherit the functionality, 
then add methods to define the application’s behavior. 
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Similarly, the compressor Simulation Framework was 
created to avoid having to define new attributes and 
methods to establish the basic functionality of new com- 
ponent classes when they are created. A new compressor 
class, which inherits the attributes and methods that re- 
late it to a more general group of compressors, is derived 
and given new methods to define its behavior, such as 
the ability to calculate a new pressure. 

Note the concept of multiple inheritance, deriving 
from more than one class base, allows a new class to 
take on an appearance resembling two other classes, such 
as combining the ControlVolume and RotatingElement 
classes to form a Compressor class. The use of multi- 
ple inheritance does tend to increase the complexity of 
the heirarchy, however, inheritance is central to avoiding 
duplicating code. Consider the diagram in Figure 18. 
Presumably, the methods necessary for handling map 
data would be the same for the two map-based objects. 
In panel A, the map routine must be duplicated in each 
of the mapped component classes. In panel B, they are 
defined once in MapElement and then inherited. 

The Simulation Framework improved the reuseability 
of the program by decoupling the distinct behavior of 
the classes of objects from their basic functionality. Fur- 
ther, by separating this functionality into classes, the 
appearance of new classes can in effect be assembled as 
desired. 

Sample Implementation 

Figure 19 shows how the MappedCompressor class was 
derived from the Simulation Framework. Multiple in- 
heritance was used to combine features nedded to define 
the basic functionality of the class, such as how to deal 
with performance maps. To give the new class its useful 
behavior, methods were added to calculate the various 
quantities associated with the compressor, such as pres- 
sure, temperature, and mass flow. Each of these methods 
was designed to calculate only one quantity. A complete 
lisiting of the class’ methods is given in detail in the 
work of Cannon(1993). Some of the methods of the base 
class, such as its constructor, had to be explicitly called 
from the derived class to ensure proper operation. Fur- 
ther, due to multiple inheritance, it was necessary to 
declare from which base class a method was derived - 
in effect, telling the computer what path to take when 
searching for the method. This strategy is not unique 
to the compressor and, for instance, can be used for the 
construction of turbines. 

A glimpse of the concept of encapsulation - hiding at- 
tributes and methods from other objects - can be seen 
in the fact that most of the calculation methods were 
declared "protected.” The effect is that only the object 
itself can call those methods. The publicly declared Run- 
Steady method takes care of calling the calculation meth- 
ods in the proper order. This technique controls the ac- 
cess to the object and its data by explicity declaring the 


interface through which other objects may interact with 
the MappedCompressor object. Figure 20 is an example 
of C++ code illustrating the implementation of public 
and private data. 

To create an operation program, the necessary objects 
- those defined back in the design phase - were instanti- 
ated from the appropriate classes. Instantiation of an ob- 
ject involves creation of a new object, and its preparation 
for operation within the program by assigning pointers 
and set objects to indicate the associations and calling 
the initialization methods. Once instantiated, the ob- 
jects can be manipulated by the main function to form 
a functional program; in the present exercise, the main 
function consists of a very simple menu-type user inter- 
face. 

Although the code is relatively simple in its operation, 
it provides a concrete demonstration of how object-based 
technology can be used to rapidly construct and inte- 
grate new classes of objects into a working simulation. 

Discussion 

Outside of the obvious technical advance in simulation 
practice the 00 codes represent, three important lessons 
reinforced in the development process are (a) the value 
of the business decision to think in terms of disposable 
prototypes (versus evolutionary prototypes) during soft- 
ware development projects, (b) syntax complexity and 
relationship generalizations demand significant attention 
to code documentation, and (c) the time scale for intro- 
ducing the object-oriented perspective into an organiza- 
tion is much larger than the time scale for the learning 
curve of the programming language itself. The failure to 
advance an awareness of the nature of the prototyping 
desired and the technology matriculation don’t sound 
like compressor technology issues, but if ignored, these 
issues can be as difficult to overcome as the modeling of 
the physics. 

Some surprising aspects of the program concerned 
what in hindsight might not seem exceptionally hard to 
have predicted. First, the development of an graphic 
user interface is an essential feature of the software sys- 
tem, not just ”afun and interesting thing” to do. A rea- 
sonable interface is transparent to the user - an interface 
is often only noticed when it does not work well . Second, 
the concept of "zooming” between differing levels of sim- 
ulation fidelity (needed if the code is to truly be a bridge 
for diverse time and length scales) brings into light the 
benefit of standards (geometric and interface). Again, 
these issues do not have an evident "fluiddynamic” look 
and feel to them, but represent the technology discipline 
overlap one must deal with in attempting to "do things 
differently.” 

Our exploration into this new method of simulating 
compression system behavior is not marked by a signifi- 
cant difference in predicted component performance (we 
hoped it would be the same as before), but moreso by 
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a new path to get there. In principle, this investment 
(time and money) is warranted only if the work to re- 
produce existing ” dusty card deck” capabilities results 
in methods that truly have the potential to bridge dis- 
ciplines and integrate codes in a seamless fashion across 
modern computing platforms. 

Concluding Remarks 

Object-oriented technology has been employed in this 
research project to identify an appropriate simulation 
framework for gas turbine components. Two programs 
were developed and were validated against DIGTEM. A 
mixed language implementation of the object-oriented 
design was sucessful. The concept of zooming was ex- 
plored for the C++ compressor, but issues associated 
flowfield integration must be addressed before the zoom- 
ing concept can be implemented within the necessary 
connector objects. 

The object-oriented approach to the dynamic engine 
represents a major paradigm shift for system and com- 
ponent simulation; specific benefits are: 

1. Object-oriented code modularity is amenable to dis- 
tributed or parallel processing hardware platforms, 

2. Methods and data are more closely related, and a 
rational hierarchy exists for the gas turbine system, 

3. Strict (and enforceable) code syntax improves code 
maintainability and reusability. 

It is proposed that this approach to code development, 
when executed on parallel/distributed processing envi- 
ronments (with the appropriate operating systems), now 
provides a realistic basis on which to explore simulations 
with sub-system component modules of differing fidelity 
(i.e., different length and time scales). This process of 
’zooming’ (entertaining various levels of fidelity with a 
given calculation sequence) holds great promise for those 
dynamic simulations where, for instance, performance at 
’out-of-range’ design conditions are unknown, or where 
a new compressor model behavior is of interest ’in-situ’. 

The initial implementation of intercomponent mixing 
volumes for the LISP code did not strictly adhere to the 
00 philosophy, but the significant lesson learned was 
the need for the correct level of component abstraction 
during the analysis phase. Mixing volumes for tradi- 
tional simulation derive from the convenience of proce- 
dural mathematics, and were not selected as the result 
of a rigorous 00 analysis and design effort. In contrast, 
a more rigorous 00 approach was taken in the CODE 
exercise, for which the fundamental premise for volume 
definition emerged in the appropriate light. Further- 
more, the disposable viewpoint on the Lisp prototype 
allowed formulation errors to be viewed as lessons to be 
carried forward; as such, subsequent simulation develop- 
ment was not haunted by the need for software patches 
and work-arounds. 


Although the prototypes mentioned in this work are, 
in fact, prototypes, it nonetheless has been instrumental 
in successfully demonstrating the salient features of an 
object-oriented perspective. Object-oriented design ap- 
proaches for gas turbine system simulation do work ... 
they are working now! 
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Figure 1. Compressor map showing flutter boundaries (from Carta, 1989). 
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Figure 2. Simulation development process. 




Firgure 4. Propulsion system component level model (GLM). 
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Figure 5. Typical map-based compressor module 


Non-Dimensional Component Representation 



14 




ENGINE ELEMENT 



Figure 7. Baseline simulation heirarchy. 


9*9 

*99 


COMPRESSOR class 


(defclass compressor (enthalpyadding rotator) 

( (points-efficiency :initarg s poi nts-ef f i c i ency 

:accessor poi nts-effi ci ency 
• type list) 

(design-efficiency :initform ( make-i t-array 0.0) 

;initarg : desi gn-ef f i ci ency 
:accessor design-efficiency 
: type array ) 

(efficiency :initform ( mak e-i t -a rray 0.0) 

:initarg tefficiency 
:accessor efficiency 
: type array) 

( t empe ra t u r e-c o r r ec t i on-c oef :initform (make it array 1.0) 

: accessor tempera ture - cor rec tion-coef 
; type array) 

(temp-interpolation-const timtform ( make-i t-ar ray 0.0) 

: i ni targ : temp-i nterpolat ion-const 
: accessor temp-interpolati on- const 
: type array) 

: initform nil . * 

;accessor input-rotationa 1-connector) 


(input-rotational -connector 


(documentation " i ne compressor class")) 


\\\ VARIABLE-COMPRESSOR class 

(defclass variable-compressor (variable compressor) 
( ) ) 


;;r" _ BLEED-C00LED-C0MPRESS0R Class 

(defclass bleed-cool ed-compressor (bleed-cooled compressor) 
( ) ) 


Figure 8. Example code for Compressor Lisp Classes. 
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(add-component Variable-compressor 
component-name "l PC 

:points-ma$s-flow *(193.5 140.0 100.0 193.5 193.5) 
ipolnts-efficlency *(0.8270 0.8097 0.7098 0.7803 0.7807) 
rpoints-variabie-stator-angle *(-1.7004 -24.990 -24.990 -2.5004 -2.5) 
rbias-variablestator-angle 0.0 
:base-perf-map Vusr/npss/map-dbase/digtem-lpc.map** 
rvariable-parf-map "/usr/npss/map-dbase/digtem-vlpc.map") 

(add-component Variable-compressor 
component-name "HPC 

polnts-mass-ftow *(107.0 72.5 50.0 107.0 107.0) 
rpoints-efficiency *(0.8298 0.8249 0.7582 0.8189 0.8189) 
rpolnts-varlable-stator-angle *(4.0 -4.8 -20.0 4.0 4.0) 
±ias-vartable-stator-angle 4.0 
:base-perf-map "/usr/npss/map-dbase/dtgtem-hpc.map** 
rvarlable-perf-map Vusr/npss/map-dbase/digtem-vhpc.map* 1 ) 


(connect-engine-elements "LPC-ROTOR" m lPC m 
(connect-engine-elements ■HPT" •HPI-ROTOR* 
(connect-engine-elements "HPT-ROTOR" "HP-SHAFP 
(connect-engine-elements "HP-SHAFT "HPC-ROTOR" 
(connect-engine-elements "HPC-ROTOR* "HPC" 


Figure 9. Example of instantiation and coupling 


UPDATE-C0MPRESS0R-IEVEL2-DIGTEM 

The foreign function call to DIGTEM subroutine 


C def foreign 'update-compressoi — level2-digtem 
:entry-point ( convert-to-lang "compressor" 

« language i f ortran) 


* arguments '((simple-array 
(simple-array 
( simple-array 
(simple-array 
(simple-array 
(simple-array 
(simple-array 
(simple-array 
(simple-array 
(simple-array 
(simple-array 
(simple-array 
(simple-array 
(simple-array 
(simple-array 
( simple-array 
(simple-array 
(simple-array 
(simple-array 
(simple-array 
(simple-array 
(simple-array 
(simple-array 
(simple-array 
(simple-array 
(simple-array 
(simple-array 
(simple-array 
(simple-array 

: return-type j void 
slanguage : f ortran) 


single-float 

(D) 

p i 

single-float 

<1>) 

t p 

single-float 

( 1 ) ) 

p » 

single-float 

(D) 

# j 

single-float 

(1)) 

p p 

single-float 

Cl)) 

p i 

single-float 

CD) 

i 1 

single-float 

CD) 

p p 

single-float 

CD) 

j t 

single-float 

(D) 

j ; 

single-float 

CD) 

i p 

single-float) 

p p 

single-float) 


p p 

single-float) 


p i 

fixnum (5)) 


p p 

single-float) 


p i 

single-float) 


p p 

single-float) 


p p 

fixnum (5)) 


S p 

single-float 

CD) 

p p 

single-float 

CD) 

p p 

single-float 

(D) 

p p 

single-float 

Cl)) 

i p 

single-float 

Cl)) 

; ; 

single-float 

Cl)) 

p i 

single-float 

Cl)) 

p p 

single-float 

Cl)) 

; ; 

single-float 

Cl)) 

; ; 

single-float 

Cl))) 

p p 


COMPRESSOR (engl/eng2) 


pressure-in 
design pressure-in 
pressure-out 
design pressure-out 
temperature-in 
design temp-in 
temperature out 
rpm spool 
design rpm spool 
design mass flow in 
enthalpy in 
base map 1 
base-map 2 

base map 3 -in/output 
base map 4 -in/output 
var map 1 
var map 2 

var map 3 -in/output 
var map 4 -in/output 
var input effect cvgp 
correction mass flow 
correction temperature 
design efficiency 
temperature interpolation const 
mass flow -output 
efficiency -output 
variable effect -output 
enthalpy-out -output 
energy term -output 


Figure 10. Illustration of FORTRAN call from within Lisp. 
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Before 


After 


SUBROUTINE ENG2 ( P3 , P22 , XNH , T22 , CVGP , WA22 , ET AHC , CSHI FT ) 

PARAMETER ( NXP2 = 1 1 , NCV2 = 1 A , NS2 = 2) 

COMMON /MPCVG/FX2(NCV2),F2(NXP2,NCV2,NS2),FSV2(NS2),N2(6) 
PARAMETER ( NXPA=1 2 , NCVA=1 A , NSA = 3 ) 

COMMON /MPCPB/FXA(NCVA),FA(NXPA,NCVA,NSA),FSVA(NSA),NA(6) 


COMMON /CONST/ AQL1 3 , AQL6 , VI 3 , V3, VA, VA1 , V6 , V7 , XIH , XIL , BSFVGP , 
X BSCVGP, CCC 50 ) , BETAHC, BETAB, BETAAB 
COMMON/ ENG22D/ P22D, T22D, WA22D, ETAHCD 
COMMON/ ENG3D/P3D, T3D, WA3D, H3D, GM3D 

COMMON/ENGAD/PAD,TAD,WGAD,HPAD,DHAD,XNHD,HBLHTD,WBlLTD,WBLOVD 


SUBROUTINE COMPRESSORC PIN, PIND, POUT, POUTD, TIN, TIND, TOUT, 

X XSPOOL,XSPOLD,WDOTID,HIN,PMAPl, PMAP2, PMAP3, MAPA, 

X PMAP1V, PMAP2V , PMAP3V , MAPAV, CVGP, WCORR,TCORR, ETACOD, BETACOM, 
X WDOTIN, ETACOM, CSHI FT , HOUT , EOUT) 


Figure 11. Rehabilitated FORTRAN subroutine. 



Figure 12. Sample prototype GUI for system simulation. 
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Figure 13. Comparison of Lisp and baseline calculation results. 



Figure 14. Objects and associations for C + + compressor. 
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i ►- rrv 

bypass 

Figure 15. Fundamental component representations. 




Figure 17. Simulation framework. 
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'iDCompressor^ 


Desired Result U 


Figure 19. Map-based compressor class. 
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// 


! / 

// r 

//i 

//i 

//i 

//i 

* *Map** 

Base Class: None 
Base For: None 

Description: Contains the map data and handling 

routines 

i 

i 

i 

i 

i 

u\ 

** ATTRIBUTES** 


i 

//I 

mapFile : name of file containing map data 


i 

//I 

curves : number of curves on the map 


1 

//I 

points : number of points on the map 


i 

//I 

x : 2-D array of abcissa values 


1 

//I 

y : 2-D array of ordinate values 


i 

//I 

//I 

2 : 1-D array of values differentiating the curves 

i 

i 

//I 

♦♦MEMBER FUNCTIONS** 


i 

//I 

Map : constructor : loads map data 


i 

//I 

LoadMap : reads the map values from the .MAP file 


i 

//I 

PrintMap : prints the map values to the screen 

on desired map 

i 

//I 

InterpolateMap : performs bivariate interpolation 

i 

//I 

//I 

-Map : destructor 


i 

i 

//I 

♦♦NOTES** 


i 

//I 

Creation Date: 12/07/92 


i 

//I 

Last Update: 01/04/93 


i 

//I 

Compiler: Borland Turbo C++ Version 3.1 


i 

//I 

//I 

SGI UNIX C++ Compiler 


i 

i 

//= 

=====Class Def ini tion==== : ~===“~-============= : ===== : 

- 




class Map 

{ 

protected : 

char *mapFile; 
int curves; 
int points; 
float x [20] [20] ; 
float y [20] [20] ; 
float z [20] ; 

public: 

Map ( char* , int , int ) ; 

void LoadMap { ) ; 

void PrintMap ( ) ; 

void InterpolateMap ( ) ; 

float InterpolateMap ( float, float) ; 

-Map ( ) { } ; 


//======End Class De f inition==~==========- : 


C + + model is available from: 
astovl@heifer.lerc.nasa.gov 


Figure 20. C+ + code illustrating public and private data. 
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